Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reworking Sorting Module for Consistency #61

Merged
merged 9 commits into from
Aug 12, 2023
Merged

Reworking Sorting Module for Consistency #61

merged 9 commits into from
Aug 12, 2023

Conversation

CodingTil
Copy link
Contributor

See Issue: #37

I had to revert commit c9a3ea6 as it did not successfully sort descending arrays.

I based my rework on the proposal in #37 (comment)

  • Trait for an inplace function
  • Trait for an function that returns a value
    Note that inplace here does not refer to whether the actual sorting algorithm is inplace, i.e. requires no extra space (https://www.geeksforgeeks.org/sorting-terminology/), but rather do denote whether the output is stored in the same memory location of the input or not.

Let me know whether these changes follow good practice and are practical.

@CodingTil
Copy link
Contributor Author

I hope one can squash commits in the PR.

Copy link
Owner

@alexfertel alexfertel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall great job, thank you for the thorough review & contribution ❤️

I had to revert commit c9a3ea6 as it did not successfully sort descending arrays.

Oh, good catch! I missed this 🚀

just use a Sorter Trait everywhere, and then provide two methods: sort and sort_inplace

Could you elaborate on why you didn't just use one Sorter trait? I was thinking something like:

pub trait Sorter<T: Ord + Copy> {
    fn sort_inplace(arr: &mut [T]);

    fn sort(arr: &[T]) -> Vec<T> {
        let mut result = arr.to_vec();
        Self::sort_inplace(&mut result);
        result
    }
}

I think I would rather have the trait implementation after the sorting function itself. That is, if you were to read top-to-bottom, you would find the algorithm first, and then the abstracting traits. This appeals better to someone new to Rust/someone that just wants to read the algorithm itself. What do you think?


I hope one can squash commits in the PR.

Yeah, no worries, I always squash before merging and give it an appropriate name 👍🏻

src/sorting/bogo_sort.rs Outdated Show resolved Hide resolved
src/sorting/macros.rs Show resolved Hide resolved
@CodingTil
Copy link
Contributor Author

Could you elaborate on why you didn't just use one Sorter trait?

I think in the beginning I wanted to avoid having to require the trait Copy (or Clone) for all the T's. So, if I could find a way to do without both, or just using Clone, I would've chosen that approach.
But I guess I have often simply called sort_inplace from sort anyway, thus requiring Copy almost everywhere.

Let me know if I should change it to your proposal. I do see that yours is a lot easier to read.


I think I would rather have the trait implementation after the sorting function itself. That is, if you were to read top-to-bottom, you would find the algorithm first, and then the abstracting traits. This appeals better to someone new to Rust/someone that just wants to read the algorithm itself. What do you think?

Yeah, that sounds like a good idea. Will do!

Co-authored-by: Alexander González <[email protected]>
@CodingTil
Copy link
Contributor Author

I think in the beginning I wanted to avoid having to require the trait Copy (or Clone) for all the T's. So, if I could find a way to do without both, or just using Clone, I would've chosen that approach.
But I guess I have often simply called sort_inplace from sort anyway, thus requiring Copy almost everywhere.
Let me know if I should change it to your proposal. I do see that yours is a lot easier to read.

Ah, what the heck. I am basically using Copy already everywhere. I'll use your proposal!

@CodingTil
Copy link
Contributor Author

Alright, applied the suggestions. Requesting review :)

Copy link
Owner

@alexfertel alexfertel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! Excellent PR tbh, I see you did quite a few small things in addition like removing some casts and removing some unnecessary trait bounds. Thank you!

@alexfertel alexfertel merged commit 75c9d83 into alexfertel:main Aug 12, 2023
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants